The present invention relates to communication systems and services for distributing digital content, and more particularly, to techniques for accessing a network through two or more alternative networks, while providing appropriate Quality of Service (QoS) through the alternative networks.
In currently existing communication networks, subscribers can access the Internet through access networks provided by cable or DSL operators. Similarly, mobile customers can receive mobile service (e.g., cellular phone service) through cellular network provided by their cellular provider. Mobile customers may use, for example, the TDM (time division multiplex) circuitry of the cellular network to make voice calls.
As more services become IP enabled, service providers or operators have innovative ways of delivering these services. One example of such an IP enabled service is voice over IP (VoIP), where voice information is digitized, turned into IP packets, and sent over the Internet to the receiving ‘phone.’ Such innovative delivery techniques are becoming available for many services, another important example being video based services.
Some providers are beginning to leverage their IP networks for the delivery of services that mimic those of mobile services. For example, recently-available phones can operate in a ‘multi-mode’ function. Multi-mode refers to the fact that these mobile devices can ‘attach’ to different networks using entirely different technologies. An example of a multi-mode device (also referred to herein as a “combophone”) is one that can communicate via a wireless local area network (WLAN) based on the WiFi standard (IEEE 802.11), as well as 3G (CDMA and GSM based 3GPP2/3GPP standards, respectively) and traditional TDM protocols. With a multi-mode device, all of these capabilities are built into a single mobile unit that can attach to a WiFi network, or a 3G mobile data network, or even the traditional TDM circuit based mobile network. The reason for the multi-modality is that depending on the strength of the network signal (which would directly impact the service quality), the operational cost of such a network, or other operational considerations, an advantage may exist for the device to use one particular network over another, in order to deliver a particular service.
Due to weak cellular signals at a user's home, a multi-mode mobile unit may attach to a WiFi network instead of using the regular TDM based cellular network, and initiate a VoIP session via the WiFi network in order to make a phone call. The WiFi network is typically provided by a home WiFi device/gateway, which attaches to a high speed data network (e.g., cable broadband, xDSL or fiber) at the terminal end of the WiFi link. The VoIP traffic is often encapsulated in an IP tunnel (typically, this tunnel is implemented with IPSEC). The VoIP traffic is ‘tunneled’ through the access network provider's (e.g., Cable or xDSL or fiber operator) network and is brought all the way back to the mobile service provider's IP based network. Once the VoIP traffic reaches the mobile service provider's network, the IP tunnel is ‘terminated’ and the VoIP traffic that was transported through the tunnel is extracted and communicated in the mobile provider's network. Ultimately, the VoIP traffic terminates in a voice gateway to be converted back into TDM traffic.
In this example, the subscriber's ‘home network’ is the mobile provider's network, because the application infrastructure responsible for serving the subscriber is in the mobile network. The cable or xDSL network through which the device tunneling is considered to be the visited network.
FIG. 1 illustrates the general packet formatting used to create a tunnel as described above. An un-encapsulated packet 10 includes an IP header 12, a UDP header 14, and MIP control data 16. In order to form an IP tunnel, the original packet 10 is embedded within an encapsulated packet 20 by adding an ESP header 22, an ESP trailer 24, a NAT-T UDP header 26 and an IPSEC IP header 28 (these are referred to in general below as “encapsulating headers” or “tunnel headers”). In general, network components that implement the tunnel ignore the IP header 12 and the UDP header 14, and only evaluate the NAT-T UDP header and the IPSEC IP header 28.
Sending information through a tunnel as described above complicates the provision of appropriate QoS for the tunneled content. Consider the network architecture shown in FIG. 2, in which a multiple system operator (MSO—e.g., cable) network is depicted in the lower portion of the figure, and a wireless service provider network (in this example, Sprint) is depicted in the upper portion of the figure. FIG. 2 illustrates the steps necessary to request QoS for the session from the dual mode phone 30, through the MSO network to the Sprint network.
In the first step [1], the client signals to the SIP Edge Proxy 32, using its address IPmp to identify itself.
In the second step [2], the SIP Edge Proxy 32 signals to the PS 34 in the mobile network using IPmp as the identifier for the subscriber phone 30.
In the third step [3], the PS 34 figures where in the MSO network the peer PS 36 resides (using the address IPmp). The simplest way to perform this function is to map the address to the list of subnets associated with a particular peering PS. This information may be provisioned/configured on the PS, or it may be learned from the network. The PS 34 in the mobile network signals the QoS policy request to the correct PS 36 in the MSO network using the IPmp to identify the client.
In the fourth step [4], the PS 36 in the cable network identifies the correct cable modem termination system (CMTS) 38 (or edge device) to control (the device behind which the subscriber/client is located) and issues the messaging to the CMTS 38.
In the fifth step [5], the CMTS 38 (or edge device) issues the appropriate signaling with the cable modem in the home with the WiFi access point 40 to affect the QoS for the media traffic over the access network (in this example, it is the DOCSIS network).
In the sixth step [6], the media stream for the dual mode phone 30 traverses the visited access network (i.e., the MSO network) with Quality of Service—the stream is identified by the CMTS 38 using the IPmp address (as packets associated with the media stream will have the IPmp as the source IP address in the IP header of the packet).
The example described above accesses the Sprint network (the home network of the dual mode phone through the visited MSO network without the use of tunneling. The packets traversing the two networks use the same header information (i.e., the client IP headers) regardless of through which network they are passing, so the SIP proxy 32 in the Sprint network informs the peering policy server 36 which packets are to be given enhanced QoS through the visited network by simply identifying the packet's client IP headers.
Providing QoS in a network environment that uses tunneling to convey packets through the visited network is more complicated, because the encapsulating headers used to convey the packets through the visited network are typically not the underlying client IP headers of the packet, as described relative to FIG. 1. Once the SIP proxy 32 receives the packets, the encapsulating headers have already been stripped from the packets. On the other hand, the peering policy server 36 and the underlying cable MSO visiting/serving network identify the packets associated with the session with the encapsulating/tunnel headers. The visited network is typically unaware of the header inside the packet and can only operate on the sessions based on the tunnel header. The SIP proxy 32 signals to the policy server 34 in the Sprint network using the address of the underlying client IP header (because it does not have the tunnel address). The Sprint policy server may signal to the Cable MSO policy server 36 the address of the client. However, this address differs from the tunnel IP address, and thus does not provide the correct information to enable policy server 36 to identify the correct edge device/CMTS that is responsible for enforcing QoS for the session, nor would the edge device be able to correctly identify the packets associated with the client's session.